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Abstract 

In the last fifteen years, the high performance computing (HPC) com- 
munity has claimed for parallel programming environments that recon- 
ciles generality, higher level of abstraction, portability, and efficiency for 
distributed-memory parallel computing platforms. The Hash component 
model appears as an alternative for addressing HPC community claims 
for fitting these requirements. This paper presents foundations that will 
enable a parallel programming environment based on the Hash model to 
address the problems of "debugging", performance evaluation and verifi- 
cation of formal properties of parallel program by means of a powerful, 
simple, and widely adopted formalism: Petri nets. 



1 Introduction 

Haskell# is a parallel extension to Haskell [6], the most widely used non-strict 
pure functional programming language [25] . It makes possible the coordination 
of a set of functional processes written in Haskell through a configuration lan- 
guage, called HCL (Haskell # Configuration Language). Thus, Haskcll# sepa- 
rate the programming task in two levels: the computation level, where functional 
processes are written in Haskell, and the coordination level, where functional 
processes are coordinated. The coordination media of Haskell^ is also called 
the Hash component model. In recent works, we have generalized the Hash com- 
ponent model in order to support other programming languages than Haskell 
at the computation level. Functional processes are now units, possibly written 
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in any programming language supported by a programming environment that 
complies to the Hash component model. In this paper, we still suppose that 
units are the functional processes of Haskell^. 

The coordination level of Haskell^, i. e. the Hash component model, was de- 
signed in order to make possible to translate the coordination media of Haskell # 
programs onto Petri nets. This paper addresses the issue of presenting a transla- 
tion schema for that, demonstrating its use to formal analysis of them, involving 
verification of formal properties. The use of Petri nets allows for reusing existing 
automatic tools based on this formalisms for reasoning about Hash programs, 
such as PEP [3] and INA [5T]. Further extensions could make possible perfor- 
mance evaluation using timed or stochastic Petri Nets variants [UJ [25] . 

In the rest of the paper, we use the Hash component model to refer to the 
coordination level of Haskell^, i.e. it is assumed that functional processes are 
written in Haskell (functional modules) and they communicate through either 
stream-based or singleton communication channels that link their input and 
output ports. Such concepts are not present in the general definition of the 
Hash component model. 

In additional to this introduction, this paper comprises the following sec- 
tions. Section [5] presents additional details about the Hash component model. 
Section [3] presents a translation schema of Hash programs onto Petri nets. Sec- 
tion 2] demonstrates how Petri net models of Hash programs may be used for 
verification of formal concurrency properties of Hash programs. 

2 The Hash Component Model 

Distributed parallel programs may be viewed as collections of processes that in- 
teract by exchanging messages during execution. Current programming models 
provide the ability to describe computation of processes by augmenting com- 
mon languages with notations for explicit message passing. However, they do 
not provide ability to modularize concerns that appear in the design of paral- 
lel applications, including the concern of parallelism itself, which are scattered 
across the implementation of processes. We advocate that this is the key feature 
for integrating advanced software engineering techniques in the development en- 
vironment of HPC parallel applications. In sequential programming, the focus 
is on modularization of concerns, since there are a unique conceptual "process" 
and efficiency requirements are less restrictive. This is the essential difference 
that makes sequential programming actually more suitable for current software 
engineering techniques for large scale applications than current parallel pro- 
gramming. 

The Hash component model may be viewed as a new paradigm for develop- 
ing message passing programs. Now, they may be viewed from two orthogonal 
perspective dimensions: the dimension of processes and the dimension of com- 
ponents. 

A process correspond to the related notion derived from conventional mes- 
sage passing programming. Thus, they are agents that perform computational 
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tasks, communicating through communication channels. Conceptually, Hash 
channels, like in OCCAM |17j . are point-to-point, synchronous, typed and uni- 
directional. Bounded buffers are also supported. The disciplined use of channels 
is the feature that makes possible formal analysis of parallel programs by using 
Petri nets, the main topic of this paper. 

A component is an abstract entity that address a functional or non-functional 
concern of the application or its execution environment in the parallel program. 
A component describe the role of a set of processes with respect to a given 
concern. The sets of components that respectively implement a set of concerns 
may overlap, allowing for modular separation of concerns that are interlaced 
across implementation of processes (cross-cutting concerns). The separation of 
cross-cutting concerns is an active research area in object-oriented program- 
ming of large scale applications |19) . A Hash program is defined by a main 
component that address the overall application concern. Some common exam- 
ples of cross-cutting non-functional concerns that appears in HPC applications 
are: placement of processes onto processors, secure policies for accessing com- 
puting resources on grids, fault-tolerance schemes for long-running applications, 
parallel debugging, execution timing, and so on. 

Hash programming is performed from the perspective of components, instead 
of processes, but resulting in the specification of the topology of a network of 
parallel processes. 

Components may be composed or simple. Composed components are pro- 
grammed using the Hash configuration language (HCL), being built by hierar- 
chical composition of other components, called inner components. HCL may be 
viewed as a language for gluing and orchestrating components, i.e. a connec- 
tor language. It is distinguished from other compositional languages because it 
supports composition of parallel components by overlapping the concerns they 
address. Conventional compositional languages only allows nested composition 
of sequential components. Simple components addresses functional concerns, 
implemented using a host language, supposed to be sequential. Simple compo- 
nents are the atoms of functionality in Hash programs, constituting the leaves 
in their component hierarchy. 

The Hash component model supports parallel programming with skeletons 
[11] without any additional language support. Partial topological skeletons may 
expose topological patterns of interaction between processes in a Hash program, 
which may be used to produce more efficient code for specific architectures and 
execution environments [8]. They are implemented as composed components 
parameterized by their addressed concerns. 

The Hash component model has origins in Haskell^ [6], where the host lan- 
guage used to program simple components is Haskell. Haskell enables separation 
between coordination and computation code, by attaching lazy streams to com- 
munication channels at coordination level, avoiding the use of communication 
primitives in communication code [5]. This paper on focused in Haskell^. 

In the next section, it is described how composed components, and skele- 
tons, are programmed using Hash configurations, while programming of simple 
components, in Haskell, is described in Section [2721 
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Figure 1: Component Perspective versus Process Perspective 



2.1 Programming Composed Components 

Composed components define coordination media of Haskell^ programs, where 
all parallelism concerns are addresses without mention to entities at computation 
levels, where computations are specified. Composed components are written in 
HCL (Hash Configuration Language). Also, they define the core of the Hash 
component model, supported by Haskell 

The configuration of a composed component specifies how a collection units, 
agents that perform specific tasks, interact by means of point-to-point, typed, 
and unidirectional communication channels, for addressing a given parallel pro- 
gramming concern. For that, a unit is instantiated from an interface and as- 
sociated to a component (Figure [21). The latter specifies the task performed 
by the unit, since functional modules describe addressed concerns, while the 
former specifies how the unit interacts with the coordination medium. A unit 
associated with a simple component is called process, while a unit associated 
with a composed component is called a cluster. A interface of a unit is defined 
by a set of typed input and output ports and a protocol. The protocol of an 
interface specifies the order in which ports may be activated during execution of 
the units instantiated from that interface, by means of an embedded language 
whose constructors have semantic equivalence to regular expressions controlled 
by semaphores. This formalism is equivalent to place/transition Petri nets, al- 
lowing for formal property analysis, simulation and performance evaluation of 
programs using available Petri net tools [10], such as PEP [16] and INA [21]. 
A port is activated between the time in which it becomes ready to perform a 
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interface declaration unit declaration assign declaration 



Figure 2: Instantiating and Configuring a Unit 
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Figure 3: Unification/Factorization 



communication operation and the time it completes this operation, according 
to the communication mode of the channel where the port is connected. 

Units interact through communication channels, which connect an output 
port from an unit (transmitter) to an input port of another one (receiver). The 
types of the connected ports must be the same. The supported communication 
modes, inspired on MPI, are : synchronous, buffered and ready. 

In a unit specification, interface ports can be replicated to form groups. 
Groups may be of two kinds: any and all, according to the semantics of acti- 
vation. The activation of a group of ports of kind all implies activation of all 
its port members. The activation of a group of ports of kind any implies that 
one of the port members will be put ready for communication but only one will 
complete communication. The chosen port is one of the activated ports whose 
communication pairs are also activated at that instant. From the internal per- 
spective of the unit, groups arc treated as indivisible entities, while from the 
perspective of the coordination medium, port members are referred directly in 
order to forming channels. Input and output ports (groups individually) of the 
unit interface must be mapped to arguments and return points of the component 
assigned to it, respectively. Wire functions are useful when it is necessary to 
transform values at the boundary between ports and arguments/exit points. A 
particularly useful use of wire functions is to aggregate data received from input 
ports belonging to a group of ports of kind all to a unique value, passed to the 
associated argument. Similarly, wire functions allow that a value produced in 
an exit point to be mapped onto a collection of values in order to be sent by the 
port members of the associated group of output ports of kind all. Wire functions 




Figure 4: An Illustrative Example of Replication 
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Figure 5: Topology of Matrix Multiplication Using a Torus 



increases the changes for reusing a component, resolving possible conflicts. 

Two operations are defined on units: unification and factorization. Unifica- 
tion allows to unify a collection of units, forming a single unit. Factorization is 
the inverse of unification, allowing units to be divided into many virtual units. 
Replication, a third operation applied to units, allows that the network induced 
by a collection of units to be replicated. All operations assume that units are 
fully connected. Behavioral and connectivity preserving restrictions are applied, 
but not formalized here. Connectivity restrictions imply the possibility of to 
replicate ports whenever it is necessary to adjust topological connectivity after 
an operation. Figures |3] and |4] present illustrative examples of these operations. 

2.1.1 Virtual Units and Skeletons 

To allow overlapping of components and the support for skeletons, the notion 
of virtual unit has been introduced. A unit is virtual whenever there is no 
component associated with it. In other terms, the task performed by a virtual 
unit is not defined. Components are partially parameterized in its addressed 
concern by means of placing virtual units in its constitution. A component that 
comprises at least one virtual unit is called an abstract component, or a partial 
topological skeleton. These terms are used as synonyms. When a programmer 
re-use an abstract component for specification of a Hash program, it must to 
assign components to the virtual units comprising it. 

Abstract components may not instantiate applications. It is necessary to 
describe the computation performed by their constituent virtual units. The 
assignment operation is used allows to associate a component to a virtual unit, 
making it a non-virtual unit. Also, there is a superseding operation, which 
allows to take a non- virtual unit for replacing a virtual unit of the topology. The 
behavioural compatibility restrictions from the non- virtual unit to the replaced 
virtual unit guarantees that any sequence of communication actions that is 
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Figure 6: Composing Pipe-Lines to Form a Systolic Mesh 



valid in the non- virtual unit remains valid in the virtual unit. The superseding 
operation is a "syntactic sugar" of HCL, since it may be implemented using 
unification and assignment. 

Figure |6] shows how a skeleton describing a systolic mesh of processes, imple- 
mented by overlapping a collection of pipe-line skeleton instances. The abstract 
components PipeLine is used to describe interaction of processes placed at the 
mesh lines and columns. Each unit in SystolicMesh abstract component is 
formed by two slices: one described by the unit that comes from the vertical 
PipeLine component and the other described by the unit that comes from the 
horizontal one. 

2.2 Programming Simple Components 

Simple components, also called functional modules, are atoms of functionalities 
in Hash programming. The collection of simple components in a Hash program 
describes its computation media. Simple components might be programmed 
virtually in any general purpose language, called host language. For that, it is 
needed to define which host language constructions correspond to the arguments 
and return points of the underlying functional module. It is preferred that no 
extensions to the host language be necessary for this purpose, keeping trans- 
parency between coordination and computation media. Simple components may 
be overlapped when configuring composed components. The goal is to imple- 
ment a really multi-lingual approach for parallel programming. For that, it has 
been proposed to use CCA (Common Component Architecture) [2], a recent 
standard proposed for integrating components written in different languages in 
a parallel environment. Another possibility is to use heterogeneous implemen- 
tations of MPI [MlES], recently proposed, facilitating this task since, in cluster 
environments, Hash programs are compiled to MPI. 

Since the translation schema onto Petri nets is defined on top of coordination 
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component CPlPELlNE <N> with 

iterator i range [1,N] 

interface I C Pipe where 

ports: i* o* 

protocol: repeat seq{o!; i?} until <o & i> 

[/ unit pipe[i] where ports: ICPipe /] 

connect pipc[i]— ¥o to pipe[i+ 1] ■*— i, buffered 

component Torus <N> with 

use Skeletons. Common. CPlPELlNE 

iterator i, j range [1,N] 

interface ITorus where 

ports: ICPipe @ n — J- s # ICPipe @ c — ► w 
protocol: repeat seq {par {s!; w!}; par {n?; e?}} 
until <n & c & s & w> 



[/ unit vpipefi 
[/ unit hpipe[j 



i CPipeLine<N> to vpipe[i] /] 
■ CPipeLine<N> to hpipc[j] /] 



[/ unify vpipe[i].pipe[j], hpile[j] .pipe[i] 

to node[i][j] where ports: IToru. 

component FARM<N> with 

unit distributor where ports: () — > job 
unit worker where ports: job —¥ result 

protocol: seq { job? ; 
unit collector where ports: result — > () 



suit!} 



connect distributor .job to worker. job, synchronous 
connect worker. result to collector . result, synchronous 



replicate N: • 



component SqMatMult < N > where 

iterator %, j range [l.N] 

use Skeletons. Common. {TORUS, Farm} 
use MMShift 

interface ISqMatMult where 
ports: j r # ITorus 

protocol: seq {j?; repeat seq { s! ;e! ;n? ; w? } 
counter JV } 

unit mm.torus; assign ToRUS<N> to mmioms 
unit mm_farm; assign FARM<N> to mmiarm 

[/ unify farm.workerfi + j X JV] , torus. node[i] [j] 

to sqmm[i][j] /] where ports: ISqMatMult 

unify farm. distributor, farm. collector , sqmm[0][0] 
to sqmm_root where 

ports: () -J" ab # C -»• () # 

ISqMatMult © mm 
protocol: seq {ab!; c?; do mm } 

[/ assign MMShift to aqmm[i][j] /] 

module MMSHlFT(main) where 

mam :: Num t t — >■ t — > [t] — > [t] — > ([t],[t],t) 
main a b as_i bs_i — (as_o,bs_o,c) 
where 

c = matmult as_o bs_o 

(as_o, bs_o) — (a:as_i, b:bs_i) 

matmult :: Num t => t — >■ [t] — >■ [t] — >■ t 
matmult [] [] = 

matmult (a:as) (b:bs) = a*b + matmult as bs 



Figure 7: Configuration Code of Matrix Multiplication on a Torus 



module Tracking(mam) where 

import Track 
import Tallies 
import Mcp.typcs 

main :: User_spec_info — > [(Particle, Seed)] — > ([ [Event] ],[Int]) 

main user_info particlcjist = let events's = map f particlejist in (events's, tally _bal event-lists) 
where 

f (particle@(_,_,_, e, _), sd) = (Create_source e):(track userjnfo particle [] sd) 

Figure 8: A Functional Module from MCP-Haskell # 



8 



<CoMPONENT> — ► component ( { u ^ : < UNIT > , . . ., it^:<UNIT>}, { c i : <CHANNEL> , 



cj : <CHANNEL>}) 



<UNIT> unit (id, {p 1 :<PORT>, . . ., p fc :<PORT>}, <TYPE W >) 
<TYPE U > — ► repetitive | non-repetitive 

<Behavior> — > protocol ({id^ em , . . . , id^ em }, <Action>) 

<Action> — > skip 

| seq {ai : < AcTION> ; . . .; a fc :<AcTION>} 
| par {a\: <ACTION>; . . .; a. k :< ACTION > } 
j alt {gi : < AcTION> ; . . .; g^ : < AcTION> } 
j repeat_until (<ACTION>, C) 
j repeat_counter (<Action>, N) 

repeat_forever <AcTION> 

signal id 

wait id 

activate id 

<PORT> — ► port (id, <DlRECTION> , <MuLTIPLICITY> , <TYPEp> ,nesting-f actor) 
< Multiplicity > — > single | group (<TYPE g >, {pi :<Port>, . . ., p ti :<Port>}) 
<DlRECTION> — > input | output 
<TYPEp> — > stream | non-stream 
<TYPE g > -> any | all 

<CHANNEL> — > connect (idP ort , idP ort , <C'HANMODE>) 
<CHANMODE> — > synchronous | bufFered [ ready 



Figure 9: Abstract Hash Configuration Language Syntax 



media, abstracting from computation media concerns, specific details about 
programming simple components is not provided in this paper. For illustration, 
Figure[8]presents an example of functional module from MCP-Haskell# program 
[9], written in Haskell. 

2.3 An Abstract Representation for Hash Components 

In Figure 12. 2\ it is denned a simplified syntax for an abstract representation 
of Hash configurations, named Abstract Hash. The abstract Hash configuration 
language (AHCL) only captures information strictly relevant to the translation 
schema onto Petri nets further presented. For example, interface declarations 
and operations over units, such as unifications, factorizations, replications, and 
assign operation are not represented in AHCL. It is supposed that these opera- 
tions are all resolved before translation process. AHCL is not a simplification. 
Indeed, in the compilation process of Hash configurations, AHCL correspond 
to the intermediate code generated by the front- end compiler module, which 
serves as input to all back-end modules. A back-end was developed for generat- 
ing PNML (Petri Net Markup Language) code from a Hash configuration. The 
following paragraph describes the structure of AHCL. 

A component is composed by a set of units (u\, . . . ,u{) and a set of chan- 
nels (ci, . . . , cj). Units are described by an identifier, a collection of ports 
(< Port >). A unit can be repetitive or non-repetitive (< Type u >). The 
interface of a unit is defined by a collection of ports and a protocol, described 
by means of an embedded language that specifies valid orders for activation of 
ports. This language have constructors equivalent to combinators of regular 
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Figure 10: Translating a Component 

expressions controlled by balanced semaphores. A port is described by an iden- 
tifier (id), a direction (< Direction >), a type (stream or non-stream) and a 
nesting factor. Additionally, port multiplicity specifies if a port is a single port 
or a group of ports. Notice that a group of port can be of two types: any or all. 
All port identifiers are assumed to be distinct in an abstract Hash programs. A 
channel connect two ports and is associated to a mode (synchronous, buffered 
and ready). Notice that, abstract Hash syntax does not force that these two 
ports be from opposite directions. This restriction is implicitly assumed. 

3 Translating Hash programs into Petri Nets 

In this section, a schema for translating Hash programs into Petri nets is intro- 
duced. In order to make translation schema easier to understand, it is informally 
described using diagrams. The possibility of making intuitive visual descriptions 
is an interesting feature of Petri nets. 

The translation schema is specified inductively in the hierarchy of compo- 
nents at the coordination medium of the Hash program. Thus, simple com- 
ponents are ignored. The overall steps in the translation procedure of a Hash 
program into an interlaced Petri net are: 

1. Translating units: For each unit comprising the component (unit decla- 
rations), its interface is used for yielding an interlaced Petri net describing 
activation order of their interface ports. In Hash configuration language, 
it is defined by an embedded language, in interface declarations, whose 
combinators have correspondence to operators of regular expression con- 
trolled by semaphores. This formalism was proved to have expressiveness 
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Interface or Interface Class Virtual Unit Unit (non-virtual) 




interface declaration unit declaration assign declaration 



Figure 11: Unit = Interface (by instantiation) + Component (by assignment) 



equivalence to Petri nets according to formal language theory. If a unit is 
a cluster (a composed component is assigned to the unit), it is necessary to 
generate the Petri net that corresponds to the assigned component. Using 
information about mapping of argument /return points to input/output 
ports of the unit, it is possible to synchronize behavior of the unit with 
behavior of the component, in such way that they are compatible; 

2. Synchronize units. Now that a Petri net exists for describing communi- 
cation behavior (traces) of each unit, communication channels (connect 
declarations) may be used for coordinating synchronized behavior of these 
Petri nets (units); 

3. Synchronize streams. For each port carrying a stream, a Petri net de- 
scribing a protocol for stream synchronization is overlapped with the Petri 
net produced in the last step. The semantics of stream communication 
is described separately because it increases complexity of the generated 
interlaced Petri net, making computationally hard its analysis. Thus, in 
Hash programming environment, the programmer may decide not to in- 
clude stream synchronization protocol. Obviously, information may be 
lost, but it may not be necessary for some useful analysis. 

The next sections provide details about the above translation steps. Also, 
it is discussed how higher-level information encompassed in skeletons may be 
used to simplify the generated network. 

3.1 Modelling Components (T c ) 

In Figure [TUl the Petri net resulted from application of translation function T c 
to the configuration of a component is illustrated. The translation function T u 
is applied to each unit comprising the component, generating a Petri net that 
describes its communication behavior. The resulting Petri nets are connected in 
order to model parallel execution of units. The places PROCESS_STARTED[j] and 
process_finished [7], 1 < j < n, where n is the number of units, correspond 
to start places and stop places of the Petri nets modelling units, respectively. 
When a token is placed on PROCESS-STARTED [7] , the unit j is ready to initiate 
execution, and when a token is placed on process_finished[j], the unit j had 
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Figure 12: Translating Unit's Ports 



finished. The transitions process_RESTARt[/c], 1 < k < r, where r is the num- 
ber of repetitive units, allows that repetitive units return back to its initial state 
after finalization. They are introduced in the Petri net generated for each unit. 
The place program_end_ready receives a mark when all non-repetitive units 
terminates. In this case, the tokens in places PROCESS-RESTART -ENABLED [fc] , 
1 < k < r, are removed, preventing repetitive processes execute again. At this 
state, the program terminates after all repetitive processes also terminate, which 
causes transition processes_ALL_join to be fired and a token to be deposited 

in PROGRAM_END. 

3.2 Modelling Units (T u ) 

This section intends to describe how individual units are translated into Petri 
nets. Firstly, Figure fT2l presents interlaced Petri nets that model the activation 
of the ports of the interface of a unit. A mark in place PORT .prepared [p] 
indicates that the port p is prepared for communication. The firing of transition 
PORT_SENd[j»]/port_recv[p] models communication, causing the deposit of a 
mark in place port_COMPLETe[j>] for indicating that communication has been 
completed on port p. It is possible that two ports be active at the same time. 
In groups of ports, the places GROUP_PREPARE[g] and GROUP_COMPLETE[g] are 
connected to places port_prepared[p] and port .complete [p] of each port 
p belonging to the group g that model local preparation and completion of 
communication in ports belonging to the group, according to their semantics: 
any or all. In groups of ports of kind all, all individual ports are activated 
in consequence of activation of the group. In groups of ports of kind any, 
only one port is chosen among the ports that are ready for communication 
completion. For obeying this semantic restriction, the firing of a transition 
PORT_SEND[p]/pORT_RECV[p] of a port p in group g of kind any causes removal 
of the marks in places PORT_prepared[j/], for all places p' belonging to g, in 
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<ACTION> 




skip 













Figure 13: Translating "Null Action' 



such a way that all ports p, such that p ^ p, cannot complete communication 
(firing of transition PORT_SENd[p]/port_recv[p]). 

The order in which marks are placed in places port_prepared[p], for any 
p, is controlled by an interlaced Petri net that models the protocol of the unit. 
The following sections discusses how primitive actions and action combinators 
of behavior expressions are translated into Petri nets. The primitive actions 
are: skip (null action), wait (increment semaphore primitive), signal (decre- 
ment semaphore primitive), ? (activation of input port), and ! (activation of 
output ports). The combinators of actions are: seq (sequential actions), par 
(concurrent actions), alt (non-deterministic choice among n actions), and if 
(conditional choice between two actions). 



3.2.1 Null Action (skip) 

The skip combinator have no communication effect. Because that, it is known 
as the "null action" . Only one place is needed, where it is both start and stop 
place (Figure [13]) of the interlaced Petri net generated. 



3.2.2 Sequencing (seq) 

The seq combinator describes a total ordering for execution of a set of actions 
(sequential execution), represented by a\, ai, . . . , a n . It may be modelled by 
sequential composition of the Petri nets induced for each action (Figure Q3]). 

3.2.3 Concurrency (par) 

The par combinator describes a concurrent (interleaving) execution of a set of 
actions, represented by a%, . . . , a n . It may be modelled by parallel composi- 



<ACTION> seq 

<ACTION> 



Tl 



Tl Tl 



(Tl) SEQ_NEXT_ACTIONlscqJnbel, i] 



Figure 14: Sequence of Actions 
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<ACTION> 




(T2) PAR JOIN_ACTIONS[parJabelj 



Figure 15: Interleaving (Concurrency) Among Actions 



tion of the Petri nets induced by each action (Figure ITsT) . 

3.2.4 Non-Deterministic Choice (alt) 

The alt combinator describes a conceptually non-deterministic choice among a 
set of actions, represented by a\, 0,2, ■ ■ . , a n . It may be modelled by composing 
the Petri nets induced for each action using a conflict in place ALT_begin [alt_label] , 
its start place (Figure[l6|). The firing of transitions ALT _SELECT_B RANCH [altJabel , 
i]j 1 < i < n , models the choice. 

3.2.5 Streams and Conditions for Checking Stream Termination 

The two combinators modelled in the next sections, repeat and if, requires 
testing a condition in order to choose the next action to be performed. The 
condition is defined by a logical predicate in its disjunctive normal form (DNF). 



<ACTION> 
alt 




1 <ACTION> ^ 

HO Orjt 

ri 1 , T2 




Tl 







OT>i 


' 1 

Tl 






I T2 



(PI) ALT_BE(;iN[yll_label] 
(P2) ALT_END[yll_label] 



(Tl ) AL T_SELECT_BRANCH[alt_label. ij 
(T2) Ah T_END_A CTIOXjalrJabel, ij 



Figure 16: Choice Among Actions 
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Logical variables are references to ports that carry streams. This section at- 
tempts to formalize the notion of streams in the Hash component model and 
valuation of logical variables of termination-test conditions of streams. 

A stream is defined as a sequence of semantically related data items, termi- 
nated with a special mark, that is transmitted through a channel. By making an 
analogy with conventional message passing programming using MPI, a trivial 
example of stream is a sequence of data items transmitted in calls to a specific 
occurrence of MPI_Send primitive in the context of an iteration. At each itera- 
tion, an item of the stream is transmitted. The termination of the iteration is 
modelled, in the Hash program, by the end mark carried by the stream. Com- 
munication on channels that carry streams may be implemented using persistent 
communication objects in the underlying messaging passing library, which may 
reduce communication overhead. 

Hash streams may be nested. Streams of streams, at any nesting depth may 
be defined. A stream Sx , where d is the nesting factor of the stream and x is 
a positive integer that indicates the order of a nested stream in a stream, may 
be defined as following: 

c(M)f <sf +M \s< l+M \...,si l+M \EOS[i]},n>0 , if i < d 

y VALUE " ,'di = d (1) 



where VALUE is a data item and E0S[i] is a termination value at nesting level 
i. Notice that termination values should carry an integer indicating the nesting 
level of the stream being terminated. The feature of nested streams appeared 
in consequence of design of Haskell#. Streams at coordination level must be 
associated to lazy lists in computation media 0. The experience with Haskell# 
programming have shown that laziness of Haskell nested lists may be useful in 
some applications. This feature is analogous to communication operations that 
occurs in context of nested iterations in MPI parallel programming. 

In Hash configuration language, streams are declared by placing "*" symbols 
after the identifier of a port in the declaration of interfaces. The number of 
"*"'s indicates the nesting factor of the stream carried by the port. Only ports 
carrying streams of the same nesting levels may be connected through a channel. 
It is defined that a port that transmit a single value (non-streamed) have nesting 
level zero. 

Now that the notion of streams is defined, it is possible to define the syntax 
and semantics of predicates for testing synchronized termination of streams, a 
necessary feature for combinators if and repeat. This kind of predicate will be 
referred as stream predicate. 

Syntactically, a stream predicate is a logical predicate in its disjunctive nor- 
mal form. The logical operators supported are the logical and, and "|", 
the logical or. Disjunctions may be enclosed by "(" and ")" delimiters. Logical 
variables are references to interface ports of a unit. The formal syntax of stream 
predicates is shown below: 

1 In Haskell^, simple components arc functional modules written in Haskell 
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streamjpredicate — > sync-conjunctioni '|' ... '|' sync-Conjunction n (n > 1) 
sync-conjunction — y '(' simple_conjunction '}' | simple_conjunction 
simple_conjunction —> port_id | ( port_idi '&' ... '&' port_id n ) (n > 1) 

Let d be the depth of nesting of an occurrence R of a repeat or if combinator 
in relation to an outermost occurrence, if it exists (d = 0, if it does not exists). 
Only port carrying streams with nesting factor equal or less than d can appear 
in the termination condition of R. It is now possible to define semantics of 
stream predicates, by defining how values of logical variables may be inferred 
in execution of units. For instance, let p be a port carrying stream S^' n \ 
Its value is false whenever a data value (VALUE) or an ending value at nesting 
level i (EOSK]), such that i < d, was transmitted (sent or received) in its last 
activation. Otherwise, it is true. The value of the stream predicate may evaluate 
to true, false or fail. A value true is obtained by evaluating the stream 
predicate ignoring semantics of angle brackets delimiters. A fail is obtained 
if negation of some conjunction enclosed in angle brackets evaluates to true, 
assuming the following identity that defines angle brackets semantics: 



^( a (k,r) A (»(fc, r+ i) A ... A a (fe s )) = ^a (fe r ) A -'0( fciT . +1) A ... A ~'0( fci3 ) 

(2) 

If stream predicate evaluates neither to true or error, the value of the 
stream predicate is false. Angle brackets delimiters are used for ensuring syn- 
chronization of the nature of values transmitted by streams, whenever necessary. 

In order to make possible to model test of stream predicates with Petri nets, 
it is firstly necessary to model stream communication by using this formalism. 

Particularly, it is necessary to introduce, in the Petri net of the Hash pro- 
gram, places that can remember the kind of value transmitted in the last acti- 
vation of ports that carry streams. 

In a Hash program, for each port s that carries a stream with nesting factor 
n, there are two sets of n + 1 places, here referred as Stream_Flags(s) and 
Stream_Flags(s): 

Stream_Flags(s) = {stream_port_flag[s, k] I < k < n} 
Str.eam_Flags(s) = {stream_port_flag_dual[s, k] I < k < n} 



For some stream port s, the places in set Stream_Flags(s) form a split 
binary semaphore: 

V" M(p) = 1 

psStream_Flags(s) 



Also, they are mutually exclusive with its corresponding places in Stream_Flags(s): 
VA; : < k < n : M(stream_port_flag[s, fc]) + M"(stream_port_flag_dual[s, k]) = 1 



For a port s carrying a stream with nesting factor n, the places Stream_Flags(s) 
and Stream_Flags(s) are used to remember which kind of value was trans- 
mitted in the last activation of s. There are n + 1 possibilities: 
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Figure 17: Stream Controlled Repetition 



• An ending marker at nesting level i (EOS[z]), for < i < n— 1; 

• A data value. 



The places stream_port_flag[s,/c], such that < k < n — 1, are re- 
spectively associated to ending marks EOS [A;] of a port s carrying a stream 
with nesting factor n. The place STREAM_port_flag[s,7i] is associated to 
a data value. Assuming the restrictions above, if there is a mark on the 
STREAM_PORT_flag[s,/c] place, then a value of its corresponding kind was trans- 
mitted in the last activation of the port. 

All the above restrictions are guaranteed by the Petri net protocol for syn- 
chronization of streams introduced further, in Section|3]4j The next two sections 
present respectively how to model repeat and if combinators, assuming the ex- 
istence of sets of places Stream_Flags(s) and Stream_Flags(s). 



3.2.6 Repetition Controlled by Stream Predicates 

The repeat combinator is used to model repeated execution of an action. The 
termination condition may be provided in a until or a counter clause. The 
later will be introduced in the next section. The former uses a stream predicate 
for testing termination of a repetition after each iteration. In the Petri net 
modelling of repeat combinator with until clause, it is assumed existence of 
the sub- network modelling stream communication introduced in Section 13.2.51 
In Figure [l7l it is illustrated the Petri net resulted from translation of re- 
peat combinator with an until clause to check termination. The conflict in 
place ru_CHECKING_CONDITIONS models the decision on to terminate or not the 
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(PI) RC_ENTERING[r] 
(P2) RC_REMAINING[r] 
(P3) RC_PREPARED[r] 
(P4) RC_PERFORMED[r] 
(P5) RC_EXITING[r] 



(Tl)RC_ENTER[rl 
(T2) RC_START_ACTION[r] 
(T3) RC_FINISH_ACTION[r] 
(T4) RC_EXIT[r] 



Figure 18: Repeated Action by a Fixed Number of Times 



<ACTION> repeat ... forever 




RI_REPEAT[r] 



Figure 19: Infinite Repetition (repeat) 
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Figure 20: Conditional 



iteration. Values of logical variables corresponding to ports in the stream predi- 
cate are tested using their respective Stream_Flags(s) and Stream_Flags(s) 
places. The arrangement of places and transitions in Figure [17] allows for testing 
the value of stream predicates at each iteration. The mutual exclusive firing of 
transitions ru -Terminate, ru_fail and RU_LOOP correspond, respectively, to 
values true (execute one more iteration), false (termination) and error (abort 
the program) for the stream predicate. 

3.2.7 Bounded Repetition 

The combinator repeat with termination condition defined by a counter clause 
models repeated execution of an action by a fixed number of times. Its transla- 
tion into Petri nets is illustrated in Figure [TBI For a certain fixed bounded repeti- 
tion r, the weight of arcs (RC_ENTER[r], RC_REMAiNiNG[r]) and (rc_performed [r] , RC_EXiT[r]) 
(n) define the number of repetitions of < ACTION > . 

3.2.8 Infinite Repetition 

Whenever no termination condition is defined for a given occurrence of the 
repeat combinator, the given action is repeated infinitely. The Petri net that 
models this kind of repeat combinator is illustrated in Figure [T9l 

3.2.9 Conditional Choice (if) 

The if combinator describes a conditional choice between to two actions. Its 
translation into Petri nets is illustrated in Figure 1201 The reader may notice 
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(P4) SEM W AIT BEGIN 




Figure 21: signal (left) and wait (right) Semaphore Primitives 

the analogy between the construction of the Petri net in this diagram with the 
Petri net generated for the repeat ... until combinator, mainly concerning the 
test of the stream predicate. 

3.2.10 Semaphore Primitives 

The wait and signal (balanced counter) semaphore primitives and the par 
combinator make behavior expressions comparable to labelled Petri nets in de- 
scriptive power [18j . In absence of semaphore primitives, only regular patterns 
of unit behavior could be described. The semantic of semaphore primitives is 
now defined using the notation introduced in [1] for concurrent synchronization: 

wait(s): <await s > — > s := s — 1> 
signal(s): < s := s + 1 > 

The angle brackets model mutual exclusion (atomic actions in concurrent 
processes), while the await statement models condition synchronization. The 
wait primitive causes a process to delay until the value of the semaphore s is 
greater than zero in order to decrement its value. Thus, the value of a semaphore 
is greater than zero in any instant of execution of a unit. In concurrent systems 
where synchronization is controlled by balanced counter semaphores, like in 
behavior expressions here defined, the value of a semaphore must be the same 
at the initial and final states of the system. 

The signal and wait primitives are modelled using Petri nets as described in 
Figure I2T1 Given a semaphore s, the number of marks in place SEM_COUNTEr[s] 
models the semaphore value at a given state. 

3.2.11 Port Activation 

The Hash primitive actions ! and ? models respectively send and receive primi- 
tives in message passing programming. In Hash programs, they cause activation 
of groups of ports and individual ports that are not member of any group. In 
Section [3~2l the Petri net slice that model individual ports and groups of ports 
is illustrated in Figure [12J An individual port p is prepared for communication 
whenever a mark is deposited in place PORT -PREPARED [p] . A group of ports 
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of kind all is prepared whenever all of its ports are prepared, while a group of 
kind any is prepared whenever any of its ports are prepared. The communica- 
tion is completed whenever a place is deposited in place PORT .complete [p] or 
GROUP_COMPLETE[p]. The activation a of a port p is defined as the time between 
preparation of a port and completion of communication. The format of Petri 
net slices induced by translation of occurrences of primitives ! and ? is illus- 
trated in Figure [22] The firing of transition ACTlVATE_START[a] prepares port p 
for communication and firing of transition ACTiVATE_STOP[a] occurs whenever 
the port completes communication. Notice that whenever a mark is deposited 
in place ACTlVATE_ON[p], the port p is active. 

3.3 Communication between Units 

In the translation of a component, the Petri net slices resulted from transla- 
tion of their units form an interlaced Petri net that models their asynchronous 
execution. Information regarding synchronization of units, by means of commu- 
nication channels, is not yet included. In Figure [23l Petri net slices that model, 
respectively, the three kinds of channels that may occur in a Hash program 
(synchronous, buffered and ready) are presented. The translation function 
T L is applied to each communication channel in a component, generating Petri 
net slices according to the translation schema illustrated in Figure [23l These 
Petri net slices are overlapped with the Petri net slices that models behavior of 
units in order to model synchronous execution of the units. 

For synchronous channels, communication pairs must be active at the 
same time for communication to complete. For implementing that, it is only 
necessary to unify the respective transitions modelling completion of commu- 
nication from the respective pairs. For buffered channels (bounded buffers), 
the sender does not need to wait completion of communication operation for 
resuming execution. For that, whenever the sender port s in a channel c 
is activated, transition port_SENd[s] must be activated if there is a mark in 



<ACTION> 
activate 



PORT_PREPARED[porl] 



PORT_COMPLETE[purt] 



from translation 
. of ports 




(PI) ACTIVATE ENTERING[al 
(P2) ACTIVATE ON[a] 
(P3)ACTIVATE_EXITING[a] 



(Tl) ACTIVATE START[a] 
(T2) ACTIVATE FINISH[aJ 



Figure 22: Activation of Ports 
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<CHAN NLL> 



<CHAN \liL> 



(PI) PORT_PREPARED[p] 
(P2) PORT_COMPLETE|p] 

(Tl)PORT_SEND[pj 
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(T5) CHAH_READY_RECEIVER_TRY_ENTER[c] 
<T6)CllAH_READY_SENDER_OPENIcl 



Figure 23: Modelling Communication Channels 



place CHAN_BUFFER_free[c], which models the number of empty slots in the 
buffer. The place CHAN_BUFFER_used[c], which receives a mark after acti- 
vation of port_SENd[s], models the number of used slots in the buffer. No- 
tice that the sender blocks whenever there is no empty slots in the buffer. 
Channels supporting ready mode require a more complex protocol. The place 
CHAN_ready_is_OPEn[c] ensures that communication proceeds only if activation 
of the sender port precedes activation of the receiver. Notice that whenever re- 
ceiver is activated before sender, the sender cannot proceed, causing a deadlock 
that may be detected by a Petri net verification tool. Using this approach, it is 
possible to verify, for example, if a certain parallel program using ready chan- 
nels may fail in some program state during execution. Ready communication 
mode may improve communication performance of MPI programs, but unfor- 
tunately it is hard to ensure that communication semantics is safe in arbitrary 
parallel programs. The modelling of communication semantics with Petri nets 
may overcome these difficulties for debugging. 

3.4 Synchronization of Streams Protocol 

In Section 13.2.51 it was introduced two sets of places that must exist for each 
stream port s: Stream_Flags(s) and Stream_Flags(s). Additionally, re- 
strictions were introduced for their markings. They allow to check the kind of 
the transmitted value in the last activation of the port, making possible to check 
stream termination conditions that occurs in repeat and if combinators. This 
section presents a protocol for updating marking of places Stream_Flags(s) 
and Stream_Flags(s) in such a way that restrictions introduced in Section 
13.2.51 are obeyed. 

In Figure [24j it is illustrated how the network presented in Figure [22] (acti- 
vation of ports) may be enriched in order to introduce a protocol for updating 
places in Stream_Flags(s) and Stream_Flags(s), for an arbitrary stream 
port s with nesting factor n. The Petri net slice introduced have the transitions 
SP_CLEAR_flag[s,i] e SP_SET_FLAG[s,i], for < i < n as its main components. 
They are arranged in such a way that transitions inside the sets are mutually ex- 
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(T4) SP_SET_t LAGls,i} 
(T5) SP_PREPARE_PORTlsj 



Figure 24: Activation of Stream Ports 



elusive. The firing of a transition in SP_CLEAR_flag[s,z] clears the set of places 
Stream_Flags(s), by moving the mark in the corresponding cleared place 
to the corresponding place in set Stream_Flags(s). After that, all places in 
Stream_Flags(s) have exactly one mark, while all places in Stream_Flags(s) 
have zero mark. In sequence, one transition of set SP_SET_FLAG[s,i] is fired caus- 
ing the moving of a mark from one of the places in Stream_Flags(s), chosen 
non-deterministically, to the corresponding place in Stream_Flags(s). This 
sequence of actions models the test of the kind of the value transmitted in the 
current activation of the port. Notice that the moment of the choice is different 
for input and output ports. An input port only updates its Stream_Flags(s) 
after communication has been completed. This is in accordance with implemen- 
tation semantics, once only after receiving the value, the receiver may check the 
kind of the transmitted value. 

3.4.1 Ensuring Consistency of Communication 

Channel communication semantics imposes that the kind of value transmitted 
by the sender in a given activation of a stream port is the same as the kind of 
the value that the receiver receives in the corresponding activation. 

In Figure 1251 it is shown how this restriction is ensured for channels with 
synchronous and ready mode of communication. 

For the following description, consider that individual ports are groups con- 
taining only one port. Thus, consider a channel c connecting a sender stream 
port s and a receiver stream port r, both with nesting factor n. The groups 
where s and r are contained are respectively g s and g r . 

For each i, < i < n, it is necessary to create an arc that links the place 
STREAM_PORT_flag [c/ s ,i] to the transition SP_SET_FLAG[g r ,i], in such way that 
consistency of Stream_Flags(s) and STREAM_FLAGS(r) is forced after com- 
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Figure 25: Ensuring the Consistency of Streams Connected through Syn- 
chronous Channels 

munication completion. If two different senders, connected to ports belonging 
to a group g r of kind all, decide to transmit values of different nesting levels in 
a give activation of g r , a deadlock occurs. But it was possible to introduce a 
Petri net slice for detecting this event. 

Bounded buffered communication imposes a more complicated approach, 
illustrated in Figure [551 Consider that channel c have a buffer of size b. For 
each buffer slot k, < k < b — 1, in a channel connecting ports with nesting 
factor n, there is a set of places BUF_SLOT_FLAG[c,fc,i], for < i < n. They 
remember the kind of value stored in a buffer slot fc, after communication in 
a channel c. Essentially, after firing transition SP_SET_FLAG[g s ,i], the marking 
of STREAM_PORT_FLAG[g s ,«] at the moment of the activation of the group g s 
is saved in BUF_SLOT_FLAG[c,fc,i], where k is the number of the next available 
buffer slot. If all slots are filled, the sender blocks until a slot is freed by the 
receiver. 

If g r is a group of kind all (notice that all groups with one port is of kind all) , 
an arc from each place buf_SLOT_flag[c,0,i] to transition SP_SET_flag [g r ,i] 
ensures that the marking of STREAM_FLAGS(r) reflects the kind of the oldest 
value placed in the buffer by the sender, as semantics of buffered communica- 
tion imposes. If g r is a group of kind any, it is necessary to introduce the 
Petri net slice shown in Figure [27l It ensures to copy the marking of the places 
BUF_SLOT_FLAG[c,0,i] of the chosen receiver port r in g r . For that, the mu- 
tually exclusive places any_group_port_activated[?"] , for each r belonging 
to g r , remember which port of g r was chosen. They enable the appropriate 
set of transitions ANY_GROUP_COPY_FLAG[r], which are connected to places 
BUF_SLOT_FLAG[c,0,i] of the channel where the chosen port is connected. The 
marking of this set of places is copied to places ANY_GROUP_COPiED_FLAG[r,z], 
which are connected to transitions SP_SET_FLAG[g r , i\. 
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Figure 26: Ensuring Consistency Streams Connected through Buffered Channels 




Figure 27: Copying Protocol for Groups of Input Ports of Kind any 
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The arrangement of the places BUF_SLOTS_locked[c] and BUF_SLOTS_UNLOCKEd[c] 
and the transition buf_SLOTS_UNLOCk[c] avoids accesses to the buffer while it is 
being updated after a transmission. The firing of a transition BUF_SLOT_SELECT[c,fc] 
means the selection of the next empty slot. Whenever the buffer is full (n marks 
are deposited in place CHAN_buffer_used[c]), the sender must block for waiting 
that the receiver consume the contents of the first slot entry. 

After copying the kind of the value in the first slot of the buffer, it is dis- 
carded. For that, a shift operation, that occurs while a mark is deposited in place 
buf_slots_shifting[c], allows to save the marking of places BUF_SLOT_FLAG[c,fc,i] 
to BUF_SLOT_FLAG[c,fc — for 1 < k < n. 

3.4.2 Ensuring Consistency of Order of Kind of Transmitted Values 

The following example illustrates the needs for imposing one more restriction 
in the Petri net slice of the stream control protocol. For instance, consider a 
nested Haskell list of Int's with nesting factor 4. 

[[[[1] , [5,6]] , [[2,3]]] , [] , [[[[4,5,7] , [8,9]]] , [[6] , [7,9]]]] 

The correspondent stream in the Hash component model will transmit the 
following values at each activation of the corresponding port: 

{i.Eos 3, 5, 6, Eos 3, Eos 1, 2, 3, Eos 3, Eos 2, Eos l,Eos 1, 4, 5, 7, 
Eos 3, 8, 9, Eos 3, Eos 2, Eos 1, 6, Eos 3, 7, 9, Eos 3, Eos 2, Eos l.Eos 0} 

Notice that after transmitting a value Eos 2, it is not possible to transmit 
a value Eos 0, since the enclosing stream at nesting level 1 was not finalized 
yet. In this case, only values Eos 1, Eos 2, Eos 3 and a data item may be 
transmitted. 

Now, consider the general case for the transmission of given end marker at 
nesting level k. If k > 1, the next value to be transmitted may be any of the end 
markers at nesting level greater than k — 1 or a data item. If k — 0, the stream 
is finalized. Any attempt to read a value in a finalized stream is considered an 
error. 

In Figure [28l it is shown how the Petri net slice presented in Figure [24] (out- 
put port) may be enriched in order to support the restriction stated in the last 
paragraph. A mark is placed in place SP_ORDER_fail[s] whenever an attempt 
to activate a finalized stream port s (the kind of last transmitted value is Eos 
0) occurs. For each nesting level i, four places and two transitions controls the 
consistency of the order of the transmitted value. The place SP_flag_OPEn[s,z] 
receives a value whenever a value Eos i may be sent. Its mutually exclusive 
dual place, named SP_FLAG_OPEN_DUAL[s,i] allows for resetting the marking of 
SP_FLAG_OPEN[s,i] after activation. Resetting procedure is implemented using 
the next elements described here. The place SP_CLEANING_flag[s,i] has a mark 
whenever the resetting procedure is enabled for the port s in nesting level i. Its 
corresponding place SP_CLEANED_flag[s,i] has a mark after resetting proce- 
dure finishes. The transition SP_CLEAn[s,j] resets the place SP_FLAG_OPEN[s,i] 
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(PI) SP_FLAG_OPEN[s,i] 
(P2) SP_FLAG_OPEN_DUAL[s,i] 
(P3) SP_CLEANING_FLAG[s,i] 
(P4) SP_CLEANED_FLAG[s,i] 
(P5) SP_FAIL 

(Tl) SP_CLEAN[s,i] 

(T2) SP_KEEP_CLEANED[s,i] 



(T3) SP_CLEAR_FLAG[s,il 
(T4) SP_SET_FLAG[s,il 
(T5) SP_PREPARE_PORT[s] 



From Stream Output Port 
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Figure 28: Consistency of the Order of Kind of Transmitted Stream Values 



to its original state (zero marks), while transition SP_keep_CLEANED [s,i] fires 
whenever the place SP_FLAG_OPEN[s,i] is already cleaned. Notice that the tran- 
sitions SP_KEEP_CLEANED [s,i] and SP_CLEAN[s,z] are mutual exclusive, since 
SP_flag_OPEN[s,?] and SP_FLAG_OPEN_DUAL[s,i] are too. 

3.5 The Complexity of the Generated Petri Net 

After overlapping the Petri net slice that models stream communication se- 
mantics, allowing to make precise analysis about behavior of Hash programs 
at coordination level, the Petri net of simple Hash programs may become very 
large. Large Petri nets may turn impossible for programmers the analysis with- 
out help of some automatic or higher level means. Also, it makes hard and 
memory consuming the computations performed by the underlying Petri net 
tools, such as computation of reachability and coverability graphs, place and 
transition invariants, etc. These difficulties comes from transitory technologi- 
cal limitations, since processing power and memory amount of machines have 
increased rapidly in the recent years and it is expected that they will continue 
to increase in the next decades. Also, it is possible to use parallel techniques 
to perform high computing demanding analysis, but this approach has been 
exploited by few designers of Petri net tools. It is a reasonable assumption that 
parallel programmers have access to some parallel computer. 

Despite these facts, it is desirable to provide ways for helping programmers to 
work with large Petri nets or simplifying the generated Petri net. The following 
techniques have been proposed: 

• During the process of analysis, the programmer may decide not to aug- 
ment the Petri net of the Hash program with the protocol for modelling 
stream communication. This approach makes sense whenever the infor- 
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1. component IS<PROBLEM_CLASS, NUM.PROCS, MAX_KEY_LOC2, NUM_BUCKETS_LOG2, 

2. T0TAL_KEYS_LOG2, max_iterations, max_procs, test_array_size> with 
3. 

4. #dcfinc PARAMETERS (IS_Params PROBLEM_CLASS NUM_PROCS MAX_KEY_LOG2 NUM_BUCKETS_LOC2 

5 . TOTAL_KEYS_LOC2 MAXJTERATIONS MAX_PROCS TEST_AR.RAY_SIZE) 

6. 

7. iterator i range [1, NUM_PROCS] 
8. 

9. use Skeletons. {Misc. RShift, Collective. {AllReduce, AllToAllv} } 

10. use IS_FM IS Functional Module 

11. 

12. unit bs.comm assign AllReduce<NUM_PROCS, MPI_SUM, MPI_INTEGER> to bs.comm 

13. unit kb_comm assign AllToAllv<NUM_PROCS> to kb_comm 

14. unit k_shift assign RShift< NUM.PROCS > — ► _ to k_shift 
15. 

16. interface IIS (bs*, kb*, k) (bs*, kb*, k) 

17. where: hs@IAUReduce (UArray Int Int) # kb@ I AllToAllv (Int. Ptr Int) # k<mRShift Int 

18. behaviour: seq {repeat seq {do bs; do kb} until <bs & kb>; do k} 
19. 

20. [/ unify bs.comm. p[i] # bs, kb_comm.p[i] # kb, k_comm.p[i] # k to is_peer[i] # IIS 

21. assign IS_FM (PARAMETERS, bs, kb, k) -> (bs, kb, k) to is_pccr[i] # bs # kb # k /] 



Figure 29: The Configuration Code of IS Program 



mation provided by the protocol is not always necessary for the analysis 
being conducted. This is the reason for the separation of the stream com- 
munication protocol from the rest of the Petri net in the Hash program; 

• Another approach that have been proposed, but for further works, is to 
build higher level environments for analysis of Hash programs on top of 
Petri net tools. Instead of programmers to manipulate Petri net com- 
ponents, they manipulate Hash program elements of abstraction. Then, 
the analysis are transparently and automatically translated into proving 
sequences using INA tool; 

• Specific translation schemas for skeletons might be specified in order to 
simplify the generated Petri net. This approach is illustrated in the next 
section. For instance, it is defined how higher-level information provided 
by the use of collective communication skeletons might be used in the 
translation process of Hash programs into Petri nets. 



3.6 Modelling Collective Communication Skeletons 

Message passing libraries, such as MPI, support special primitives for collective 
communication. In Hash programming environment, it is defined a library of 
skeletons that implement the pattern of communication involved in collective 
communication operations supported by MPI. They are: Bcast, Scatter, 

SCATTERV, REDUCE_SCATTER, SCAN, GATHER, GATHERV, REDUCE, ALL- 

Gather, AllGatherv, AllToAll, AllToAllv, and AllReduce. In the 
next paragraphs, the use of collective communication skeletons is illustrated by 
means of an example. 

In Figure [29l the code for the Hash version of IS program, from NPB (NAS 
Parallel Benchmarks) [3] is presented. IS is a parallel implementation of the 
bucket sort algorithm, originally written in C/MPI. In this section, IS is used to 
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Figure 30: Modelling Collective Communication Skeleton Semantics 



illustrate the use of collective communication skeletons in a Hash program, mo- 
tivating definition of a specific strategy for translating collective communication 
patterns of interaction among units in a Hash program. 

In the line 9 of Figure [531 it is declared that skeleton^ AllReduce and 
AllToAllv will be used in the configuration. In lines 12, 13, and 14, three 
units are declared, named bs-comm, kb-comm and kshift. The first two have 
collective communication skeletons assigned to them, respectively AllReduce 
and AllToAllv. Since skeletons are composed components, these units are 
clusters of units that interact using the collective communication patterns de- 
scribed by the skeleton. In line 20, the unification of correspondent units that 
comprise clusters bs-comm, kb-comm and k_shift forms the units that comprise 
the IS topology. The unification of virtual units from distinct cluster allows to 
overlap skeletons. The behavior of the virtual units that result from unification, 

2 Partial topological skeletons are composed components where at least one unit is virtual. 
In the case of collective communication skeletons, all units are virtual. 
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named is.peerfi], 1 < i < num_PROCS, is specified by interface IIS. The simple 
component IS_FM is assigned to them for defining the computation of each 
process in the IS program. Notice that IS is a SPMD program, where the task 
performed by all processes is defined by the same simple component [7J. 

The interface IIS is declared from composition of IAllReduce, IAUToAllv and 
IRShift interfaces, the interface slices of IIS. The interface slices are respectively 
identified by bs, kb, and k. The use of combinator do is an abbreviation that 
avoids to rewrite the behavior of interface slices. Thus, "do bs" relates to the 
sequence of actions encapsulated in the specification of interface IAUReduce. 

Using the above conventions for overlapping collective communication skele- 
tons in order to form more complex topologies, it is simple to define a spe- 
cific translation rule for patterns of collective communication interactions. The 
identifiers of interface slices from collective communication skeletons might be 
viewed as special kinds of ports (collective ports) and the operator do as its 
activation operator. Notice that interface slices may be used in termination 
conditions of streams, like in line 18. Collective ports have no direction, since 
all processes participate in communication. All communication operations are 
synchronous. The Figure [30Fb) illustrates a Petri net slice that models a collec- 
tive communication operation. The involved ports are collective ports that cor- 
respond to interface slices of units that participates in a certain collective com- 
munication operation, defined by the cluster of units that defines it. In Figure 
l3"Ulc). it is illustrated how to augment the Petri net slice shown in Figure l3"CTb) 
with a protocol for modelling stream communication semantics. It is important 
to notice that the set of places Stream_Flags(s) and Stream_Flags(s) are 
shared by all collective ports involved in a collective operation. 

4 Petri Net Analysis of Formal Properties 

In this section, solutions for two well known synchronization problems, imple- 
mented in Hash approach, illustrates the use of Petri nets for analyzing Hash 
programs by verifying their formal properties. 

4.1 Dining Philosophers 

The dining philosophers problem is one of the most relevant synchronization 
problems in concurrency theory. Since it was originally proposed by Dijkstra 
in 1968 [12], it has been widely used for exercising the ability of concurrent 
languages and models for providing elegant solutions for avoiding deadlocks in 
concurrent programs. The dining philosophers problem is stated in the following 
way: 

Five philosophers are sited around a table for dinner. The philoso- 
phers spend their times eating and thinking. When a philosopher 
wants to eat, he takes two forks from the table. When a philosopher 
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Figure 31: Hash Topologies for the Dining Philosophers Problem 

wants to think, he keeps the two forks available on the table. How- 
ever, there are only five forks available, requiring that each philoso- 
pher share their two forks with their neighbors. Thus, whenever a 
philosopher is eating, its neighbors are thinking. 

A solution to the dining philosopher problem establishes a protocol for order- 
ing the activity of the philosophers. In Figure |3~T1 Hash topologies for solutions 
for the dining philosophers problem are presented. The first one, whose code is 
presented in Figure I3"!?ta). is an "anarchical" solution, where philosophers are 
free to decide when to think or to eat. In this solution, the reader may observe 
the use of buffered channels and groups of ports of kind any composing the 
network topology. The one-slot buffered channel allows to model the fact that a 
fork may be on the table waiting for a philosopher to acquire them. This occurs 
whenever there is one message pending on the buffer. At the beginning of the 
interaction, all philosophers have a fork and release them. When a philosopher 
releases a fork, the semantics of group of ports of kind any ensures that if there 
is a philosopher waiting for the fork, he will obtain the fork immediately. Oth- 
erwise, it is possible that the philosopher that released the fork have a chance 
to acquire the fork again. This solution does not satisfy some of the enunciated 
requisites for a good solution to an instance of the critical section problem. For 
example, if all philosophers acquire their right (left) forks, they will be in dead- 
lock. It is also possible that a philosopher never get a chance to obtain the forks 
(eventual entry). The second solution, whose code is presented in Figure , 
ensure all requisites. Additionally, it ensures maximal parallelism. In any state 
of execution, there are two philosophers eating. 

Figure [33] presents the Petri nets that model the respective behaviors of in- 
dividual philosophers in the first and in the second solutions. Figure l34l presents 
the Petri nets modelling the interaction among the five philosophers, after mod- 
elling communication channels. The figures are only illustrative, since the net- 
works have a number of components intractable by simple visual inspection. 
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component DiningPhilosophcrs<N> with 
index i range [0,N-1] 

interface IPhil where ports: (rfLget*, lLget*) —y (rLput*, rLput*) 
protocol: seq {rLput!; 

repeat seq {par {lLget?; rf_get?}; 

par {lLput!; rLput!}} 
until < lLget & rLget & lLput & rLput >} 

[/ unit phil[i] where ports: IPhil 

grouping: rf_get {neighbor, self} any, lLget {neighbor, self} any, 

rLput {neighbor, self} any, lLput {neighbor, self} any /] 

[/ connect phil [i] — >rf_put [neighbor] to phil[i-l mod N] 4— lLget [neighbor] , buffered 1 
connect phil[i] — >rf_put[self] to phil[i] «— rLget [self ] , buffered 1 

connect phil [i] —ylLput [neighbor] to phil[i+l mod N] <— rLget [neighbor] , buffered 1 
connect phil [i]— ylLput [self] to phil[i] <— lf_get [self ] , buffered 1 /] 

(a) 

component DiningPhilosophcrs<N> with 
index i range [0,N-1] 

interface IPhil[0] where ports: (rLget, lLget) — y (rLput, rLput) 

protocol: repeat seq {lf_put!;rf_get?; lLget?; rLput!} 

interface IPhil[l] where ports: (rLget, lLget) — y (rLput, rLput) 

protocol: repeat seq {rLget?; lLput!; rLput!; lLget?} 

[/ unit phil [i] where ports: IPhil[i mod 2] /] 

[/ connect philfi] — yrLput to phil[i-l mod N]<— lf-gct, buffered 
connect phil [i]— ylLput to phil[i+l mod N]<— rf_get, buffered /] 

(b) 



Figure 32: Hash Code for the First Solution of the Dining Philosophers Problem 
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(b) 

Figure 33: Petri Net Modelling Behavior of One Philosopher 

4.1.1 Proving Properties on the Dining Philosophers Solution 

In this section, INA (Integrated Network Analyzer) is used as an underlying 
engine for verifying formal properties about the above Hash solutions for the 
dining philosophers problem. INA allows to perform several structural and dy- 
namic analysis on the Petri net induced from the two solutions. Among other 
possible analysis approaches, INA provides model checking facilities that allows 
to check validity of CTL (Constructive Tree Logic) formulae, describing prop- 
erties about the Hash program, on the reachability graph of its corresponding 
Petri net. CTL is a suitable formalism, from branching-time temporal logics, for 
expressing and verifying safety (invariance) and liveness properties of dynamic 
systems. It allows temporal operators to quantify over paths that are possible 
from a given state. There exist a superset of CTL, named CTL*, that augments 
expressive power of CTL by allowing to express fairness constrains that are not 
allowed to be expressed in CTL. However, INA restricts to CTL because model 
checking algorithms for CTL are more efficient (linear in the formula size) that 
in CTL* (exponential in the formula size). 

Now, let us to introduce relevant properties that may be proved about solu- 
tions to the dining philosophers problems and to model these properties using 
CTL. The dining philosophers problem may be thought as an instance of the 
critical section problem. In fact, forks are critical sections, since it cannot be 
taken by more than one philosopher. A good solution to an instance of the 
critical section problem must ensure three properties pQ: 

• Mutual exclusion: Two adjacent philosophers cannot obtain the same 
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(a) 



(b) 



Figure 34: Petri nets for Dining Philosophers Hash Solutions 
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(a) Macros About Channels 


s 


b 


r 


SENDER.PREPARED [c] 


= POR.T_PREPAR.ED[(9o(c)] 


• 


• 


• 


RECEIVER_PREPARED [c] 


= PORT_PREPARED[0l(c)] 


• 


• 


• 


RENDEZVOUS [c] 


= sender_ready[c] A receiver_ready[c] 


• 


• 


• 


buffer_full[c] 


= ^chan_buffer_free[c] 




• 




BUFFER_EMPTY [c] 


= ^chan_buffer_used[c] 




• 




SENDER_BLOCKED [c] 


= sender_ready[c] A -iRECEIVER_READY[c] 


• 






SENDER.BLOCKED [c] 


= sender_ready[c] A buffer_full[c] 




• 




RECEIVER_BLOCKED [c] 


= receiver_ready[c] A ^sender_ready[c] 


• 






RECEIVER _BLOCKED [c] 


= receiver_ready[c] A buffer_empty[c] 




• 





(b) Macros About Ports 


i 


o 


port_pair_prepared[p] = port_prepared[<9i 
port_pair_prepared[p] = por.t_prepared[<9o o &i l(p)] 


• 


• 



(c) Macros About Groups of Ports 


all 


any 


group_prepared[G] = (Vp)gc : por.t_prepared[p] 
group_prepared[G] = (3p) g G : port_prepared[p] 


• 


• 



Table 1: Some Useful Formula Macros for Hash programming 

fork (enter critical section); 

• Absence of deadlock: A deadlock occurs whenever there is at least 
one active philosopher and all active (not terminated) philosophers are 
blocked. The classical deadlock situation in dining philosophers problem 
occurs when all philosophers acquire its right, or left, forks. In this state, 
all philosophers may not proceed and they are not finished. Thus, they 
are in deadlock; 

• Absence of unnecessary delay: If a philosopher demands its right 
(left) fork and their right (left) neighbor is thinking, the philosopher is 
not prevented from obtaining the fork; 

• Eventual entry: Each philosopher that demands for a fork eventually 
will obtain it. 

In the following paragraphs, the above properties are characterized using 
CTL formulae. But before, intending to facilitate concise and modular specifi- 
cation of complex CTL formulas, we define the notion of CTL-formula macro. A 
CTL- formula macro is new kind of CTL-formula of the form {macro .name) [qi , qi, ■ ■ ■ , 
where {macro jname) is a macro name, qi, 1 < i < n, are qualifiers. CTL- 
formulae macros may be expanded in flat CTL-formulae, by applying recur- 
sively their definitions. For instance, A CTL-formula macro is defined using the 
following syntax: 

{macrojname)[v\,V2, ■•-,««] :: / 

where {macrojname) is a name for the macro, v i} 1 < i < n, arc qualifier 
variables, and / is a CTL-formula (possibly making reference to CTL-formula 
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(a) Macros About Philosophers (p = . . . N — 1) 




PHIL.DEM ANDS_LF [p] 
PHIL_DEMANDS_R F [p] 
PHIL_POSSESES_LF [p] 
PHIL_POSSESES_RF [p] 
PHIL_IS_EATING[p] 
PHIL_IS_THINKING[p] 
PHIL_WAITING[p] 
PHIL_FINISHED[p] 
ALL_PHIL_FINISHED 


= PHIL_POSSESES_LF[p] a PHIL_POSSESES_RF[p] 
= -■PHIL_IS_EATING[p] 

= PHIL_DEMANDS_RF[p] V PHIL_DEMANDS_LF[p] 
= PROCESS-FINISHED [phil [p] ] 
= (Vp)<jv : PHIL_FINISHED[p] 




(b) Macros About Forks 


(/ = 0...AT-1) 


forkjs_free[/] - 
forkjn_use_by_right[/] = 
forkjn_use_by_left[/] = 
fork_in_use[/] = 


PHIL_IS_THINKING[/] A PHILJS_THINKING[/ffi]vl] 
PHIL_POSSESES_LF [/] 
PHIL_POSSESES_RF[/©jv 1] 

fork_in_use_by_right[/] V fork_in_use_by_left[/] 



Table 2: Some Useful Formula Macros for Dining Philosophers 



macros). In a flat CTL- formula that appears in the right-hand-side of a CTL- 
formula macro, qualifier variables are used as qualifiers for place and transition 
identifiers and for references to enclosed CTL-formulae macros. 

In Table [TJ some useful CTL-formulae macros are defined for simplifying 
specification of CTL formulae on the restrict domain of Hash programs. In Table 
[21 other CTL-formulae macros are defined, but now on the restrict domain of the 
dining philosophers problem (application oriented). Notice that CTL-formulae 
macros of Table [2] are defined on top of that defined in Table [T] Unlike the later 
macros, the implementation of the former ones is not sensitive to modifications 
in the underlying translation schema. This illustrates the transparency provided 
by the use of CTL-formulae macros in an environment for proof and analysis of 
formal properties. 

We have used INA for proving the three properties enunciated above for 
dining philosophers. The first three ones are safety properties. It may be proved 
by negating a predicate describing a state that cannot be reached in execution 
(bad state). The last one is a liveness property, for which validity of a predicate 
must be checked in all possible states. 

Proof of Mutual Exclusion. Safety property. One valid formulation for the 
corresponding bad state is: 

BAD = EF [(3/) </<jV : fork_in_use_by_right[/] A forkjn_use_by_left[/]] 

Proof of Absence of deadlock. Safety property. One valid formulation for 
the corresponding bad state is: 

BAD = EF [((Vp) ( )<p<JV : PHIL_WAITING[p] V PHIL_FINISHED[p]) A -iAll_phil_finished] 

Proof of Absence of unnecessary delay. Safety property. One valid for- 
mulation for the corresponding bad state is: 
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Figure 35: Hash Topology for of ABP (Alternating Bit Protocol) 



bad = 

EF [((Vp) </<jV : fork_is_free[/] A (phil_demands_lf[/] V PHIL_DEMANDS_RF[/©jv1]))] 

Proof of Eventual entry. Liveness property. One valid formulation for the 
corresponding good state is: : 

GOOD = AG [phil_waiting[p] => (AF [phil_eating[p]])] 

4.2 The Alternating Bit Protocol 

The alternating bit protocol (ABP) is a simple and effective technique for man- 
aging retransmission of lost messages in fault-tolerant low level implementa- 
tions of message passing libraries. Given a transmitter process A and a receiver 
process B, connected by a point-to-point stream channel, ABP ensures that 
whenever a message sent from A to B is lost, it is retransmitted. 

The Hash implementation described here is based on a functional implemen- 
tation described in [T2]. The Figure 1331 illustrates the topology of the component 
ABP, which might be used for implementing ABP protocol. The virtual units 
transmitter and receiver model the processes involved in the communication. 
The other units implement the protocol. The units transmitter, out, await, and 
corrupt_ack implement the sender side of the ABP protocol, while the units re- 
ceiver, in, ack, and corrupt_send implement the receiver side. The await process 
may retransmit a message repetitively until the message is received by process 
ack. Retransmissions are modelled using streams with nesting factor 2 (streams 
of streams). The elements of the nested stream correspond to the retransmission 
attempts of a given value. The correct arrive of the message is performed by 
inspecting the value received through the port ds. The processes corrupt_ack 
and corruptsend verify the occurrence of errors in the messages that arrive 
at the sender and receiver, respectively, modelling the unreliable nature of the 
communication channel. The Hash configuration code presented in Figure 1361 
implements the ABP component. 

The Petri net induced by translating ABP component is presented in Figure 

E3 
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component ABP with 

use Out, Await, Corrupt, Ack, In 

interface A B P .Transmitter where ports: (J — > (out*::t) 

protocol: repeat out! until out 



interface A B P-Recch 



- t where ports: (in*::t) —*■ () 

protocol: repeat in? until in 



!} until <is &c as> 



Bit) -► (as 1 ** 
repeat seq {a 



::Err (t,Bit)) 

!> until <as & bs> 



interface Out where ports: (is::t) — > (as: : (t,Bit) ) 

protocol: repeat seq {is?: as 

interface Await where ports: (as* : : (t, Bit) ,ds** : : Er: 
protocol: repeat seq { as? 

interface Corrupt where ports: (as** : : (t ,Bit) ) — > (bs* 
protocol: repeat seq {as?; t 

interface Ack where ports: (bs**::Err (t,Bit)) — > (cs**::Bit) 

protocol: repeat seq {bs?; cs!} until <bs & cs> 

interface In where ports: (bs**::Err (t.Bit)) — > (os*::t) 

protocol: repeat seq { repeat bs? until bs; os!} until <bs & os> 

unit transmitter where ports: ABP -Transmitter () —> out 
unit receiver where ports: ABP.Receiver in — > () 



(t,Bit)) 

'!; ds?} until <as' & ds>> until <as & as' &z ds> 



unit out where ports: lOut 

unit await where ports: lAwait 

unit corrupt.ack where ports: [Corrupt 

unit in where ports: Iln 

unit ack where ports: lAck 

unit corrupt.scnd where ports: ICorrupt grouping: bs*2 all 



assign Out to out 

assign Await to await 
assign Corrupt to corrupt.ack 
assign In to in 

assign Ack to ack 

assign Corrupt to corrupt_send 



connect 


* 


transmitter—* 


out 


to out-f- is 


connect 


* 


in->os 




to receiver* 


connect 




outH-as 




to awaits a 


connect 


* 


await— y as 




to corrupt. 


connect 


* 


corrupt_ack— 


ds 


to ack-*— ds 


connect 


* 


corrupt.scnd 


-S-bs[0] 


to in*— bs 


connect 


* 


corrupt_scnd 


-+bs[l] 


to ack-*— bs 


connect 


* 


ack->cs 




to corrupt. 



, buffered 



Figure 36: ABP Component 



38 



Figure 37: Petri Net Induced by ABP Component 
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A The Formal Syntax of HCL 

In what follows, it is described a context-free grammar for HCL, the Haskell^ 
Configuration Language, whose syntax and programming abstractions were in- 
formally presented in Section ??. Examples of HCL configurations and their 
meanings were presented in Sections ?? and ??. The notation employed here 
is similar to that used for describing syntax of Haskell 98 20 . Indeed, some 
non-terminals from that grammar are reused here, once some Haskell code ap- 
pears in HCL configurations. They are faced italic and bold. A minor difference 
on notation resides on the use of (. . .) ? , instead of [...], for describing optional 
terms. For simplicity, notation for indexed notation is ignored from the de- 
scription of formal syntax of HCL. It may be resolver by a pre-processor, before 
parsing. 

A.l Top-Level Definitions 

configuration — > header declaration^ . . . declaration n (n > 0) 

header — > component ID static -parameter -list* component-interface^ 

static-parameter -list — > < IDi . . . ID„ > (n > 0) 

component-interface — > portsjnaming 

declaration — > import-decl | use-decl \ iterator-decl \ interface-decl 

| unit-decl | assign-decl \ replace-decl | channeLdecl 
| unify-decl \ factorize-decl \ replicate-decl \ bind-decl 
| haskelLcode 

A. 2 Use Declaration 

use-decl — > use usespec 

usespec —> id | id. usespec \ id.{ usespeci , . . . , usespec n } (n > 1) 

A. 3 Import Declaration 

import-decl — > impdecl 

A. 4 Iterator Declaration 

iterator-decl —t iterator idi, . . ., id n range [ numeric-exp , numeric-exp ] (n > 1) 
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A. 5 Interface Declaration 

interface-decl — > interface (context =>)' ID tyvari ... tyvar^ interfacespec 
interface_spec — > interface-portsspec 

(where : interface-inheritance) ! (behavior : behavior_expressionf 

A. 5.1 Interface Ports Description 

interface-portsspec — > portspecJist -> portspecJist 

portspecJist — > portspec | ( portspeci , . . . , portspec n ) (n > 2) 

portspec — > id (*) ? (:: atype)' | id 

A. 5. 2 Interface Composition 

interface-inheritance — > interfaceslice\ # . . . # interfaceslicek (k > 1) 
interface-slice — > id @ ID | ID ports-naming-composition 
ports-naming-composition — > ports-naming 

( ports-namingi # . . . # ports -naming n ) (n > 1) 
ports-naming — > port-naming Jist -> porLnamingJist 
porLnamingJist — >• id | ( idi , . . . , id„) (n > 1) 

A. 5. 3 Interface Behavior 



behavior-expression 
action 



condition 
disjunction 
sync-conjunction 
simple-conjunction 



— > (sem idi , . . . , id„) ? : action (n > 1) 

— > par { actioni ; . . . ; action n } | seq { actioni ; . . . ; action n } 
| alt { actioni action n } | repeat action condition^ 

| if condition then action else action 
| id ! | id ? | signal id | wait id (n > 2) 

— > until disjunction | counter numeric-exp 

— > sync-conjunctioni '|' ... '|' sync-Conjunction n (n > 1) 

— > ( simple-conjunction ) | simple-conjunction 
id | ( idi & • • • & id„ ) (n > 1) 



A. 6 Unit Declaration 

unit-decl — > unit unitspec 

unitspec — > (*)' id (# unit-interface^ (wire wfsetupi , ... , wfsetupnf 

unit-interface — > ID portsjnaming-compositiow \ interfacespec 

wfsetup — > id (group-type groupspecf (: wire-function)* 

groupspec — > { idi, • • •, id n } | * numeric-exp 

group-type — > any | all 

wire-function — > ? | ea;p 

A. 7 Assignment Declaration 

assign-decl — > assign assigned-component to assigned-unit 
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assigned_component — > ID actual-parameter Jist* ports jnaming-composition' 
actual -parameter 'Jist — > < numeric-expi , . . . , numeric-exp n > (n > 1) 
assigned_unit — > gid ports jnaming-composition' 

A. 8 Replace Declaration 

replace_decl — > replace gzd portsjnaming-composition- by operand-unit 
A. 9 Channel Declaration 

channeLdecl — ► connect gid -> g«d to gid <- gid , commjmode 
commjmode — > synchronous | buffered numeric_exp | ready 

A. 10 Unification Declaration 

unify_decl — > unify operand_unit\ , . . . , operand-unit n to unitspec 

adjust wire wfsetupi , ■■■ , wfsetupk (n > 2, fc > 1) 
operand-unit — > qid # interface_pattern\ . . . # interface_pattern n (n > 1) 
interjacejpattern — > port_pattern_list -> portjpatternJList | id 
port_patternJist — > pattern | ( pattern^ , . . . , pattern n ) 
pattern — > id | @ gid | _ | __ 

A. 11 Factorization Declaration 

factorize-decl — > f actorize operand-unit to unit_spec\ . . . unit_spec n 

adjust wire wfsetupi , ... , wfsetupk (n > 2, fc > 1) 

A. 12 Replication Declaration 

replicate-decl replicate operand-uniti , . . . , operand-unit n into numericsxp 

adjust wire wfsetupi , ... , wfsetupk (n>2, k > 1) 

A. 13 Bind Declaration 

bind-declaration — »• bind gid -> gid to -> id | bind g«d <- gid to <- id 

A. 14 Miscelaneous 

haskelLcode — > topdecls 

qid -> idi '.' ... '.' id„ (n < 2) 
g/D -> IDx '.' ... '.' ID„ (n < 2) 
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B Foundations and Notations 



In this section, it is discussed the formalisms that comprise the formal frame- 
work for the development of this work, concerning modelling of communication 
behavior of processes, according to the Hash component model design principles. 

B.l Formal Languages 

The theory of formal languages will be employed as a framework for the study 
of patterns of communication interaction of Hash process in a parallel program. 
The main interest is to investigate relations between descriptive power of con- 
current expressions and Petri nets, in order to define a language for expressing 
communication behavior of processes, embedded in the Hash language. 

Definition 1 (Alphabet) An alphabet is a finite set of indivisible symbols, 
denoted by E. 

Definition 2 (Word) A word is a finite sequence of symbols of some alphabet 
E. The symbol e denotes the empty word, whose length is zero. 

Definition 3 (Kleene's Closure of an Alphabet ) A Kleene's closure of an 
alphabet E, denoted by E*, is defined as below: 

E* = {w | w is a word in E} 

Thus, any sequence of symbols in E, including e, belongs to E*. It is common 
to define E + as: 

E+ = E* - {e} 

Definition 4 Given an alphabet E 7 a formal language L is defined as follows: 

L C E* 

B.2 Labelled Petri Nets and Formal Languages 

Now, notations and definitions concerning Petri nets are presented. 

Definition 5 (Place/Transition Petri Net) A place/transition Petri net is 
a directed bipartite graph that can be formalized as a quadruple (P,T, A, Mq), 
where: 

1. P is a finite set of places, which can store an unlimited number of marks; 

2. T is a finite set of transitions. 

3. PHT = 0. 
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4- A defines a set of arcs, in such way that A C ((P x T) U (T x P)) x 
Naturais. Thus, an arc can go from a transition to a place or from a 
place to a transition. A number is associated to the arc, indicating its 
weight. For simplicity, if the weight is omitted it is one ((p, t) = (p, t, 1) ). 

5. The relation M CfxJV defines the initial marking, or the number of 
marks that are stored in each place at the initial state of the Petri net; 

From the initial marking, a Petri net defines a set reachable markings. A 
marking is reachable if it can be obtained from the initial marking by firing a 
sequence of transitions, according to firing rules, formalized in what follows. 

Definition 6 (Enabled Transition) Be II, II = (P,T,A,M ), a Petri net 
and t, t G T, a transition of II: 

t is enabled 4^ (Vp G P, 3m, n G N : (p,t,m) G A A (p, n) G M : n > m) 

Thus, a transition t is enabled if the number of marks in each one of its 
input places is greater than or equal to the weight of the arc that links it to the 
transition. 

Definition 7 (Firing Rule and Reachable Markings) Be U = (P, T, A, M ) 

a Petri net and a marking M of II. The transition from the marking M to a new 
marking M' is a side effect of firing an enabled transition t, and represented by 
the relation M — > M' , where: 

M' = MU Mi U M 
Mi = {(j>, n - m) | 3m, n G N : p G P, (p,t,m) G A, (p, n) G M} 
M = {(p,n + m) | 3m, n G N : p G P, (t,p,m) G A, (p,n) G M} 

The sub-marking Mj indicates the new marking for the input places of the 
transition t, while Mo indicates the new marking for output places of t. The 
transition can be fire if it is enabled and the effect of firing is to remove marks 
from input places and add marks to output places, according to the weights of 
the arcs that link these places to t. It is necessary to generalize this definition 
to cover the concept of (transitively) reachable marking. Thus, a marking M n 
is reachable from a mark M if there is a sequence of firing of transitions from 
M to M n : 

M % Mi% M 2 % ■ ■ ■ h M n 
This notation can be abbreviated to: 

M A M n , where a = tit 2 ■ ■ ■ t n 
The symbol a denotes a sequence of firings of transitions. 
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Definition 8 (Labelled Petri nets) Be £ an alphabet. A labelled Petri net 
is a 7-uple (P,T, A, Mo, p), where (P,T, A, Mo) is a place/transition Petri net 
and p:T->EU {A} is a function that associate transitions to a symbol in S. 
Transitions labelled with A are called silent transitions. 

Labelled Petri nets are an extension of Petri nets for generating formal lan- 
guages. There are two classes of Petri net languages. 

Definition 9 (Petri Net Language) Given a labelled Petri net H = (P, T, A, Mq, p), 

we define the formal language generated by II as: 

L(U, M ) = {p(o) | 3M : M 4 M}. 

Definition 10 (Petri Net Terminal Language) Given a Petri netH(P,T, A, Mq, p) 
and a final marking Mf, we can define the terminal language generated by II, 
with respect to Mf, by: 

T(N, M , M f ) = {p(a) | M 4 Mf) 

Given a labelled Petri net II, the language generated by II defines the pos- 
sible sequence of firing traces from its initial marking. The terminal language 
generated by II, with respect to hnal marking Mf, differs from II language 
because only that traces from M to M/ are considered. 

Definition 11 (Classes of Petri Nets Languages) We denote the class of 
all Petri net languages as £\°, and the class of all Petri net terminal languages 
as ix 1 . It is simple to demonstrable that l\° C l\ x . 

B.3 Interlaced Petri Nets 

Interlaced Petri nets are an alternative extension to labelled Petri nets, intro- 
duced in this article for simplifying specification of the translation schema of 
Hash programs into labelled Petri nets. Like hierarchic Petri nets [], interlaced 
Petri nets allows that complex and large scale Petri nets be implemented in 
a simpler and modular way. It does not modify descriptive power of labelled 
Petri nets. However, while hierarchic Petri nets allow only nesting composition 
of Petri nets, interlaced Petri nets also allow overlapping of them. Given a set of 
Petri net slices, each one addressing different concerns, they may be overlapped 
to form an interlaced Petri net. Interlaced Petri nets may also be viewed as 
Petri net slices for composing higher level interlaced Petri nets. 

Definition 12 (Interlaced Petri Nets) An interlaced Petri net H can be de- 
fined inductively as: 

1. (Base) A tuple (P,T, A, M , p, 8), where (P,T,A,M ,p) represents a la- 
belled Petri net and 6 : (P U T) — > 2 A is a function that maps Petri net 
nodes (places and transitions) onto a list of qualifiers, represents a simple 
interlaced Petri net; 
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2. (Induction) Let IIi, II2, . . . , II „ be interlaced Petri nets, called Petri net 
slices in this context fhypothesisj. IT, such that II = (IIi, II2, ■ • ■ ,n„} 7 is 
a composed interlaced Petri net f induction step). 

3. Anything that may not be formed from application of inductive rules 1 and 
2 is not an interlaced Petri net. 

Definition 13 (Unfolding Composite Interlaced Petri Nets) An unfolded 
interlaced Petri net ti is obtained from a interlaced petri net II by applying the 
transformation function a, defined below: 

1. p [(P, T, A, M , p, 5)] = (P, T, A, M , p, S) 

2. p. [< iii,n 2 , . . . ,n„ >] = u pi] up [n 2 ] u...up [n n ] (composite) 

The binary operator U correspond to the Petri net union operator, defined 
as below: 

(Pi, Ti, Aj, M 01 , P1 , 5 1 )0(P 2 , T 2 , A 2 , M 02 ,p 2 ,5 2 ) = (Pi U P 2 , T t U T 2 , A x U A 2 , M 01 U M 02 , P1 U p 2 . «1 U i> 2 ) 

Qualifiers are used to identify components of interlaced Petri nets (places or 
transitions) that must be treated as the same component. These components 
are said to be equivalent components. They may belong to distinct slices. Next, 
qualifiers and identification rules are formalized. 

Definition 14 (Qualifier) Let be a finite set of symbols. The set A is in- 
formally defined as all qualifiers that can be induced from set O. A qualifier S, 
S e A, is defined from O as following: 

• a, a E 6, is a qualifier f primitive qualifier^; 

• A tuple (01, a 2 , . . . , a n ) is a qualifier ( composed qualifier^, assuming that 
each ai, 1 < i < n, is a primitive qualifier; 

The following rule teaches how to identify equivalent vertices in an interlaced 
Petri net, using their qualifiers. 

Definition 15 (Identification of Vertices (Places or Transitions)) LetH 
be an interlaced Petri net. Consider its unfolded variant p [II] = (P, T, A, M , p, S). 
LetV be the collection of components of p [II] (PUT). The following equivalence 
relation is defined between two vertices v\ and w 2 f{i>i,i> 2 } C V): 

vt = v 2 ^ ({vi,v 2 } C T V {vi,v 2 } CF)A (<S(ui) n S(v 2 ) + 0) 
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B.4 Regular Expressions Controlled by Balanced Semaphores 
(SCRE) 



The following definitions are presented in order to introduce the class of regular 
expressions controlled by balanced semaphores (SCRE). This generalization to 
regular expressions, with descriptive power comparable to labelled Petri nets, 
will be used to model a language for specification of communication behavior of 
Hash processes. 

Definition 16 (Regular Expressions) A regular expression E over an alpha- 
bet £ is inductively defined as follows: 

1. a G X is a regular expression; 

2. X is a regular expression; 

3. is a regular expression; 

4- Be Si and S 2 regular expression. Thus, (Si), Si ■ S2, Si + S2 e, Si* are 
also regular expressions. 

Definition 17 (Regular Language) Be E a regular expression over S. The 
formal language generated by E, L RE (E), is defined in the following way: 

1. L RE {%) = 

2. L RE (X) = {A} 

3. L RE {a) = {a}, para a G S, 

4. L RE ((E)) = L RE (E) 

5. L RE {Ei.E 2 ) = {xy \ x G L RE (Ei) Aye L RE (E 2 )} 

6. L RE (Ei + E 2 ) = {x I x G L RE {Ei) VxE L RE {S 2 )} 

7. L RE (E*) = (JL RE (E 1 ) 
where: 

1. E° = X 

2. E l = E { - x E,i > 

The class of regular languages are denoted by RE. 

A previous version of the Hash language used regular expressions to model 
communication traces of processes [5]. However, Petri nets are far more ex- 
pressive than simple regular expressions for describing communication traces. 
This fact motivated us to generalize the adopted approach, using some class of 
synchronized concurrent expressions shown to be equivalent to Petri nets. Con- 
current expressions are an extension to regular expressions defined to model 
concurrency. Some authors refer to these languages as shuffle languages. 
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Definition 18 (Concurrent Expressions) Be E an alphabet. A concurrent 
expression S over E is defined by the following rules: 

1. If S is a regular expression over E, then S is a concurrent expression; 

2. If Si e S*2 are concurrent expressions, then SiQS 2 , eS 1 ; 8 are concurrent 
expressions; 

The operators and <g> distinguish, at least syntactically, non-regular con- 
current expressions. The language generated by concurrent expressions are de- 
fined below. 

Definition 19 (Concurrent Languages) Be S a concurrent expression over 
E. The concurrent language Lce(S) is defined according to the following rules: 

1. L(~ E {S) = Lf^ E {S), if S is a well-formed regular expression. 

2. L ce (SiQS 2 ) = {xiyix 2 y2 • • ■ %kVk \ xix 2 ■ • ■ x k e L CE (Si) A y x y 2 ■•■Vk& 
LCE&)}> 

3. L CE {S®)=\jL CE {S Qi ). 

where: 

1. S &0 = A 

2. S Gi = S^^OS^ > 0. 

The class of concurrent languages are denoted by CE. It is clear that CE 3 
RE, because every regular expression is a concurrent expression. But there is a 
strongest and important result that relates concurrent and regular languages. 

Theorem 1 (|22j, Relating Concurrent and Regular Expressions) If S 

is a concurrent expression that does not makes use of ® operator, then Lq E (S) 
is regular. 

Another important result gives bounds to the expressiveness of concurrent 
expressions. 

Theorem 2 (|15j, Bounds to Concurrent Expressions Expressiveness) 

If S is a concurrent expression, than Lq E (S) is a context-sensitive language. 

In order to increase expressivity of concurrent expressions, allowing than 
to express recursively enumerable languages, synchronized concurrent expres- 
sions^^ were proposed. They extend concurrent expressions with synchro- 
nization mechanisms and has been used extensively in 80 's to analyse expres- 
siveness of synchronization mechanisms of concurrency, mainly that based on 
semaphores. 
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Definition 20 (Synchronized Concurrent Expressions) Be S an alpha- 
bet and f2 a set of symbols that denote synchronization primitives, where £ and 
fl are disjoint. A concurrent expression E over £ U fl is called synchronized 
concurrent expression and the language (Ls(17)) is said to be a synchronization 
mechanism over E. A synchronized concurrent expression over £ U fl, adopt- 
ing the synchronization mechanism K, where K= Ls{fl), will be denoted by 
(E,E,n,K). 

The class of synchronized concurrent expression is denoted by SCE. The next 
definition defines the language of a synchronized concurrent expression, which 
gives a meaning for the synchronization mechanism. 

Definition 21 (Synchronized Concurrent Languages) Be (S, £, ft, K) a 

synchronized concurrent expression, where K — Ls(il). The language of S, 
L$£e(S) is defined as below: 

L SCE (S) = {h(x) | x G L CE (x),h(x) G K}, 

where the homomorphisms h and h are defined as follwing: 

j / \ (a a G £ 
^ (a)= A a en 



T( \ /A a e £ 
h{a) = \a a en 

The class of synchronized concurrent languages that uses a synchronization 
mechanism K is denoted by SCE K . 

This definition parameterizes the adopted synchronization mechanism. The 
most common are that based on semaphores, whose most significative examples 
are presented in the following paragraphs 

Be n n a set of synchronization primitives com n sfmbolos, where: 

il n = {ui,a. t | i = 1, ■••,«} 

The following semaphore-based synchronization mechanisms can be defined 
over [15]. 

1. Counter semaphore: Ls(il„) = C(n), where: 

C(n) = J L CE ((cri -cj! +cri))® (<7 2 -UJ2 + sigma 2 ))® • • • {o n ■ cu n + a n ))®) 
C = {C{n) | n > 0,whereC(0) = A} 

2. [0]-counter semaphore: Ls(n n ) = Co(n), where: 

C (n) = L CE ((o-i • wi))® {a 2 • w 2 ))® • ■ • (<r B • w„))®) 
C = {C (n) | n > 0, whereC a {0) = A} 
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3. Binary semaphore: Ls(£l n ) — B(n), where: 

B(n) = L CE ((cr 1 • ujx + ax))* (cr 2 • w 2 + sigma 2 ))* • • • (a n ■ u n + a n ))*) 
B = {B(n) | n > 0, whereB(0) = A} 

4. [0]-binary semaphore: Ls(£l n ) = Bo(n), where: 

B Q (n) = L CE ((at ■ ui))* (a 2 • w 2 ))* • ■ • (tr„ • w„))*) 
B = {B (ra) | n> 0, whereB o {0) = A} 

C, Co, B, Bo denote the sets of synchronization primitives with any number 
of primitives. 

This notation can be generalized to any synchronization mechanism other 
than semaphores. Let CE(n) be the family of synchronization mechanisms 
with n primitives. Then CE = (JCE(n), n = 0...n. Thus, C(n), C (n), 
B(n), Bo(ri) are special cases of CE(2n). A concurrent expression controlled 
by a semaphore system will be called as a semaphore controlled concurrent 
expression. 

Many important results about the expressive power of synchronized concur- 
rent expressions were presented []. But, in this work, one deserve special atten- 
tion. It establishes the equivalence of synchronized regular expressions that uses 
[0]-counter semaphores as synchronization protocol to Petri nets. Synchronized 
regular expressions arc defined below. 

Definition 22 (Regular Expressions Controlled by Balanced Semaphores) 

Regular expressions controlled by balanced semaphores (RECBS) are defined as 
[0J- counter synchronized concurrent expressions that does not make use of 
operator. 

The class of RECBS's is denoted by RECBS. Remember that theorem [T] guar- 
antees that concurrent expressions without operator are equivalent to regular 
expressions. However the presence of operator and [0]-counter semaphores 
guarantees that this kind of expression may generate a richer class of formal 
languages than simple regular expressions, a fact enunciated by the following 
theorem. 

Theorem 3 (Equivalence of RECBS to Petri nets [] ) The class of lan- 
guages generated by a RECBS is ix 1 . 

The result in theorem [3] are convenient for our purpose to make descriptive 
power of the Hash language equivalent to descriptive power of Petri nets. The 
use of RECBS avoids the use of operator. Shaw [35], when introducing 
flow expressions to make software descriptions gave two interpretations for 0: 
a parallel loop and as a sequential loop that creates a process (fork) in each 
iteration. Neither interpretation is practical in the Hash language, because it 
assumes static parallelism. 
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